The system and method of the present embodiment relate generally to enabling distributed transaction processing, concurrency control, and replication therein.
Database systems form the core of a number of applications today. Current data-driven applications typically consist of multiple tiers—the user front end tier, the application logic tier, and the database tier. Of these, the user front end resides and executes at the client machine, whereas the application logic and the database transactions are typically processed at the server. This structure can render the client input/output intensive while the server is computation bound. For applications involving computationally intensive business logic, this structure can lead to a server computation overload, which can ultimately restrict the scalability of the application. Applications that support online collaborations, and therefore can require computationally expensive conflict detection, are typical examples.
For example, in an online game, the posed transaction could be as simple as moving one player from some coordinate to another coordinate. The game logic, in order to execute this transaction, may have to check for the presence of another object at the same coordinate. Furthermore, for three-dimensional games, the game logic may have to calculate the geometry of the object being moved and other objects in the vicinity to determine the success of this transaction. Such calculations could effectively limit the throughput of transactions at the application logic tier and impact the processing of transactions in a distributed manner.
One example of the use of distributed transaction processing is a Massively Multiplayer Online Game (MMOG) which is capable of supporting hundreds or thousands of players simultaneously, and is played on the Internet. The architecture that has evolved for these games typically involves a server cluster, anchored in a single geographic area or spread over numerous geographically distant locations, to which clients or user machines connect and play. In MMOGs, the game is typically simulated within a cluster of server machines, while game clients act as viewers and input terminals to the simulation. In the typical game, servers dynamically assign views to simulation servers, and the assigned simulation server checks out game objects from a database back-end, performs operations on the objects, and checks them back in. Thus a full replica of the game state is kept in the database back-end, and the full replica is accessed through a simulation layer. Parts of the virtual world can be statically or dynamically assigned to specific simulators. Client-to-simulator ratios average between 40-to-1 and 3-to-1, and there is typically a hard limit in terms of active players per “realm” (an instance of the game). On the other hand, in peer-to-peer gaming systems, protocols such as paxos, a family of protocols for solving consensus in a network of unreliable processors, or virtual synchrony, a method of data replication for sharing information among programs running on multiple machines connected over the interne, are used to enforce a total order of events and consistency across all participants.
This type of technology typically deals with different categories of data, including small volatile data such as object and player position, health, and money, and large static data such as textures, music, and 3D models. The former category of data can raise issues of consistency in a concurrent environment, whereas the latter can raise issues of content distribution. The small, volatile data associated with the game state can be more sensitive to latency than bandwidth restrictions.
What is needed is the addition of semantics to transactions at the application logic tier so as to allow the processing of transactions in a distributed manner, in particular resolving concurrency, consistency, and latency issues of previous systems.